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ABSTRACT 


This thesis presents a model of link state advertisement generation for the SAAM 
(Server and Agent Based Network Management) architecture. The model includes 
generation and processing of link state data. In a SAAM network, a central server 
manages a region of 20-40 lightweight routers. The server learns the link performance of 
the routers from processing Link State Advertisement messages that are periodically sent 
by the routers. The server uses the information to maintain a Path Information Base to 
manage routing within the region. A router also sends a triggered Link State 


Advertisement message when one of its interfaces fails. 
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1. INTRODUCTION 


Today’s Internet only provides Best Effort service, where there is no guarantee of 
timely delivery. With the growth of Internet, demand for real-time traffic support is 
increasing. There is a need for a network management system that supports different 
classes of quality of service (QoS). 

Server and Agent based Active Management (SAAM) is a proposal developed to 
realize the goals of the Next Generation Internet (NGI) initiative, which will support all 


service classes required by the future. 


A. OVERVIEW OF SAAM ARCHITECTURE 


The current network architecture depends on standalone routers for network 
management tasks. Every router tries to know the network topology and determine every 
possible path to every other router in the network. This workload on routers must be 
minimized to provide quality of service for real-time applications. 

SAAM is designed to provide QoS (Quality of Service) support using today's 
widespread IP networks. SAAM uses an approach that takes most of the network 
management tasks from the routers and gives them to a dedicated server, called SAAM 
server. With this architecture real time network services will be provided in an efficient 
manner, while dealing with the dynamic changes in the network environment. SAAM 


will enable networks to ultimately provide integrated services. 


1. SAAM Region 


A SAAM region typically consists of 20-40 lightweight routers and a server. 
Server performs most of the network management tasks on behalf of the routers. 

To perform network management tasks effectively server collects information 
from routers in the region and maintains a Path Information Base (PIB) [Figure 1.1]. The 
server computes and identifies all valid paths between edge routers, that physically 
connect customer networks or other SAAM regions, and stores them in the PIB. When a 
flow request is received, the server uses the PIB to try to find the best path that supports 
the QoS metrics of the request. The server then informs the requesting host of the result 
with a flow response message. If the flow can be supported, the server updates the states 
of the routers on the flow path adding the necessary routing entry for the flow to their 


routing table, with a flow routing table update message. 


SAAM server 


path 
path-id parameters 


routing table 


flew-id next-hop foi 


router 





Figure 1. 1. SAAM Region and Building the PIB (Path Information Base) [From Ref.6]. 


2. The Path Information Base and Service Level Pipes 


The server maintains the network topology and routing information in its PIB. The 
PIB includes every valid path from each source to each destination in the region. Every 
path has specific QoS parameters associated with it. In an integrated services network 
requires each link shared by a set of logical service level pipes (see Figure 1.2). Each of 
these service level pipes provides a particular level of network performance primarily 


measured by packet delay, and packet loss rate. [Ref. 7] 


Service pipes 





Figure 1. 2. Link and Service Level Pipes [From Ref.6] 


Each flow request is made for certain type and level of network QoS. The source 
will invoke a reservation protocol such as RSVP to establish a flow to the destination. 
This request is translated into SAAM format by the edge router used by the source. The 
edge router then forwards to the server. The server consults the PIB and tries to find a 
series of service level pipes whose composite QoS meets the requirements of the flow. 
Since routes are calculated at the server, there is no need for routers to handle change in 
the network conditions. Their resources can be dedicated to packet forwarding and value 


added services (e.g. packet authentication). 


QoS management for the NGI should handle the dynamically changing network 
conditions. The QoS requirements of real-time data are measured in milliseconds. When 
a degradation of the performance of a path causes violation of the QoS requirements of 
active flows. New paths should be assigned to the affected flows. All this demands the 
network management system to be proactive, able to detect and react to changing network 


conditions within fraction of a second. [Ref. 8] 


3. Hierarchical Organization of the SAAM Servers 


SAAM organizes the servers in a hierarchy to address the scalability issue. SAAM 
partitions the network into autonomous regions each consisting of a limited number of 
routers. One server is assigned to each region, managing all routers. The server needs an 
accurate picture of the region to manage real-time traffic. The PIB should be updated 
regularly to maintain accuracy. More frequent updates mean more accurate PIB. But 
updates consume network bandwidth. A compromise should be reached between the level 
of accuracy and consumed bandwidth. 

In Figure 1.3, the SAAM network has a two level hierarchy. Each server controls 
the immediate children of its region, which can be a router or a server of a lower level 
region. A base level server gathers link performance information from routers and 
advertises itself as a router to top level server. 

A base level server only responds flow requests forwarded by an edge router in its 
region. If a flow needs to traverse multiple regions, a higher level server will also be 


included in processing request. The higher level server establishes a flow through regions 


and distributes the QoS requirements of the flow among the regions. The server of each 


makes the routing decisions inside the region. 
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Figure 1. 3. Hierarchical Organization of the SAAM Servers [From Ref.6]. 


B. BENEFITS OF SAAM 


The goal of SAAM is to provide QoS for real-time traffic flows using a central 


resource management scheme. Benefits of SAAM include: 


1. Integrated and Differentiated Services 


SAAM will support both Integrated and Differentiated services in addition to Best 
Effort service. SAAM uses a service level pipe for each service class and allocates 


resources according to user requirements. 


2. Fault Tolerance 


The server is the main player in each SAAM region. It performs admission control 
and allocate resources. A failure of the server will have a dramatic effect on the 
performance of the region. A failure must be detected timely and recovery actions be 
taken as soon as possible. SAAM uses a backup server that will manage the region in 


case the primary server fails. 


3. Auto-configuration of Control Channel 


Server builds up a control channel between the server and the routers, that is a 
spanning tree of the region in which the control traffic flows, by auto-configuration. 
Control channel is refreshed at small intervals, so that server can adapt to changes in 


network status quickly. 


4. Scalability and Incremental Deployment 


SAAM is designed to support hierarchical routing (see Figurel.3). Servers may 
be deployed incrementally, providing improvements of network performance to ISPs that 


use SAAM. 


C. SCOPE OF THIS THESIS 


The goal of this thesis is to develop an efficient scheme for generation and 
processing of Link State Advertisement (LSA) messages, and to integrate this scheme 
with the existing SAAM architecture. The SAAM server needs to have an accurate 


picture of the current performance of the routers to make good routing decisions. This 


includes a LSA generation method that will keep the server informed about the current 


network performance. 


D. MAJOR CONTRIBUTIONS OF THIS THESIS 


This thesis adds LSA generation and processing to the SAAM architecture. A 
router monitors the link state of its interfaces and reports the state information by LSA 
messages to its SAAM server. The server processes LSA messages and updates its PIB 
accordingly. With periodic LSA updates, the server always has up-to-date information 


about the network status. 


E. ORGANIZATION 


This thesis is organized with the following chapters: 

e Chapter II presents the terminology information of existing routing algorithms 
and their link state advertisement generation strategies. 

е Chapter III describes our Link State Advertisement generation and processing 
model. 

e Chapter IV describes the implementation of the model. 

e Chapter V summarizes the implementation results, lessons learned, and the 


future work. 
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II. BACKGROUND 


A. ROUTING 


A node in a network often needs to know whether another node in the same 
network or in another network is reachable. The node also should know the exact 
direction (next hop) to use for a reachable destination. There must be a network wide 
mechanism in place to provide the necessary information. This mechanism is called 
routing. 

Routing is accomplished by means of routing protocols that establish mutually 
consistent routing tables in all the nodes. Each node builds up its routing table from 
information about its own links and data received from other nodes. From the routing 
table, each node calculates best paths to reach other nodes or networks. Based on the 
calculations, each node creates a table called forwarding table, which contains the 
appropriate next hop to each reachable destination. Later when the node receives a 
packet, it consults the forwarding table using the packet’s destination address as key, and 
forwards the packet to the next hop returned for that destination. [Ref. 2] 


There are several issues that routing protocols must address: 


1. Scalability 


Requiring the whole network topology to build routing tables may not be that big 
a problem for a small to mid-sized network. But when the network size is big, it is 


practically impossible for a node to know the whole topology and make routing decisions 


in an efficient manner. Routing protocols should use hierarchical routing to scale well in 


big networks. 


2. Size of Routing Table 


The size of a routing table increases as the network size increases. So does the 
overhead to maintain the routing table. When dealing with a big network, aggregation of 
topology data is necessary to reduce the memory space used by routing tables. 
Hierarchical routing localizes the affect of a network topology change. This in tum 
decreases the route calculation and lookup overhead as well as communication cost 


associated with topology information exchanges among nodes. 


3. Robustness and Adaptability 


Routing algorithms should avoid creating loops and oscillations in the network. 
They should protect themselves by periodic consistency tests. When a topology change 
occurs, routing algorithms should respond to the change and converge fast to avoid loops 


and oscillations. 


4. Path Optimization And Load Balancing 


A selected path should be optimal regarding some performance metric. A best 
path may not necessarily be the shortest path. Depending on the metric, it may be the path 
with the least delay, or with the lowest monetary cost. Routing algorithm should use 
more than one path for each destination and res the network traffic among these 


paths to balance the load and increase the network performance. [Ref.1] 
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B. ROUTING ALGORITHMS 


Routing algorithms can be classified into two major classes: distance vector 
routing and link state routing algorithms. They have the following features: 
e They are distributed algorithms; every node in the network runs these algorithms 
independently. 
e They assume that a node knows its neighboring nodes and the cost of reaching to each 
neighbor node. 
e They both construct a routing table that contains an entry per destination. Each entry 
consist of the route cost and the next hop to the destination. 
Each node exchanges topology information with neighbors using update packets. 
The circumstances to create update packets are similar in both algorithms. One of these 
circumstances is the periodic update. Each node automatically sends an update packet at 
each period. Periodic updates enable the neighboring nodes to know that the node is 
alive. Another circumstance is the triggered update. Although both algorithms use 
triggered updates, the triggering events are different. In distance vector routing, a node 
generates a triggered update packet whenever it receives an update that causes a change in 
its routing table. In link state routing a node generates triggered updates when it detects 


that one of its links or neighbors is down. [Ref.2] 


11 


1. Distance Vector Routing 


As mentioned, every node is assumed to know its neighbor nodes at start. Each 
destination is initially assigned a cost of infinite, except for the neighbors. Nodes running 
distance vector algorithm exchange entire routing tables with neighbors. When a node 
receives a routing table from one of its neighbors, it uses that table to update its own. If 
the cost to a destination in the neighbor table plus the cost of the link to the neighbor is 
less than the cost given in its own table, the node updates its routing table by designating 


the neighbor node as the next hop to that destination. 





Figure 2. 1. Distance Vector Algorithm on Node A. 


In Figure 2.1, at start A only knows the distance to its neighbors (left table). After 
receiving B's table it learns that it can reach C by a distance of 2. A adds C to its table 
with B as the next hop (middle table). D's table does not change A's table, since the 


advertised distance to reach C is not less than the current distance to C (right table). 
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Since table exchanges are done hop by hop, distance vector algorithms suffer from 


slow recovery from link failures, and during the recovery time routing loops may occur. 


(4) (в) 0) 


Figure 2. 2. Count to Infinity Problem. 


Distance vector routing also suffers from a count to infinity problem. This 
problem can occur between two neighboring nodes. In Figure 2.2, node B detects that the 
link to C is down and updates its table. B sends its table to A, but at the same time it 
receives A's table showing a cost of 2 to reach to C, less than the one it has currently. So 
it updates the table with a cost of 3 and next hop as A, and advertises its table to A. In the 
previous table exchange A has learned the link failure but when it receives B's table it 
updates its routing table with a cost of 4 and B as the next hop. This situation continues 
until the cost reaches infinite. [Ref. 1] 

One of the techniques for preventing count to infinity is named split horizons. In 
this method nodes will not advertise a route back to the same node they received the 
update. Another technique is called split horizon with poison reverse. This technique 
advertises the update back to the neighbor but with a negative information to ensure it 
won't use the update to count to infinity. Both techniques prevent count to infinity 
between two neighboring nodes, but they can not address a count to infinity problem 


among more than two nodes. [Ref. 2] 
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a. Routing Information Protocol (RIP) 


Routing Information Protocol 1s the most widely used routing protocol in 
the Internet today. RIP is a distance vector algorithm. It uses hop count as the cost 
metric to calculate the best routes. So RIP tries to find the minimum-hop route to a 
destination. 

Every link is assigned a distance (cost) of one. Valid distances are 
between 1 and 15, 16 representing the infinity. The metric does not take the available 
bandwidth or the link utilization into account. So RIP will prefer a three hop 10MBps 
route to a 5 hop 10Gbps route. This makes RIP suitable for small networks where 
simplicity of implementation and configuration is more important than performance 
requirements. 

Nodes running RIP send periodic updates every 30 seconds by default. If a 
node does not hear from a neighboring node for three update cycles (180 sec.), it declares 
that the neighbor is down. RIP protocol uses split horizon with poison reverse to avoid 
the count to infinity problem. [Ref 1] Also when a node's table changes because of 
another node's update, it sends a triggered advertisement to its neighbors. 

RIP can be configured to use different routing metrics. It can support 
multiple address families aside from IP. Unlike RIP version 1, RIP version 2 has some 


functionality that supports hierarchical routing. 
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2. Link State Routing 


In link state routing, like distance vector routing, a node is capable of finding out 
the state of each of its links including the link cost. Each node disseminates this 
information to its neighbors. Each neighbor in tum forwards the information to its 
neighbors except for the one it get the information from. This way the network is flooded 
by the link state information of each node and every node has enough knowledge of the 
network to build a complete map of the network. Link state routing relies on controlled 
flooding of this link-state information since it calculates routes from the sum of link state 
knowledge. 

Each node prepares a packet called Link State Advertisement (LSA) that contains 
the id of the node, a list of neighbors and the cost to each neighbor, a sequence number, 
and a time to live. This LSA packet will be stored at each neighboring node for the time 
to live period duration. When this period expires, the LSA is removed. This ensures that 
an old LSA will be removed from the network eventually. 

The sequence number and time to live are used to make the link state routing 
reliable. The sequence number ensures that each node has the latest LSA from each 
neighbor. A node simply discards any incoming LSA that has an older (smaller) sequence 
number than the LSA that is currently stored in the node. 

When a node knows the whole topology, it can find a physical path to any 
reachable destination. The node, using the database of LSAs first builds a spanning tree 
where the node itself is the root. Dijkstra’s shortest path algorithm is used to form the 


spanning tree. The algorithm uses a set, P, for the reachable nodes. Every node, that 
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should be in P must be reachable using a path started with a node already in P. Algorithm 
starts with adding the root to P and continues until every node is added to P. [Ref.1] 
Figure 2.3 shows the link state algorithm on node A. At start A only knows the 
distances to D and B. When it receives the LSA of B, it learns that it can reach C with a 
cost of 4, using B as the next hop. Later after receiving and processing D’s LSA, A learns 
that it can reach to C with a smaller cost. It updates its routing table with D as the next 
hop for all entries. Even though B is a directly connected neighbor, A uses D as the next 


hop to B since the route as smaller cost. 


Next Hop 





Figure 2. 3. Link State Routing on Node A. 


a. Open shortest path first (OSPF) 


OSPF is a link state routing protocol of choice in today’s networks. OSPF 
is designed to run internal to a single autonomous system. Each OSPF router maintains 
an identical database describing the autonomous system’s topology. From this database, 


a routing table is calculated by constructing a shortest path tree. OSPF recalculates routes 
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quickly in face of topological changes, incurring a minimum of routing protocol traffic. 
[Ref. 1] 

OSPF allows sets of subnetworks to be grouped together, adding 
additional hierarchy within an AS. Such a grouping is called an area and its topology is 
hidden from the rest of the autonomous system. This information hiding enables a 
significant reduction in routing traffic. An area is a generalization of an IP sub-net. Area 


border router advertises the link state advertisements that describe the area. [Ref. 1] 
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Figure 2. 4. OSPF Areas in Autonomous Systems. 


All OSPF routing protocol data exchanges are authenticated. This means 
that only trusted routers can participate in the AS’s md This is a nice feature since a 
misconfigured router can advertise that it can reach every destination in the network with 
a cost of 0. This could eventually bring the whole network to a halt. OSPF allows use of 


different authentication methods. There is an “Authentication Type” field in the LSA 
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header. Users can set this value according to their needs and come up with their own 
authentication scheme. [Ref. 2] 

OSPF routers use a sub-protocol, named Hello Protocol, to establish and 
maintain neighbor relationships. Hello messages are also used to detect that a neighbor is 
alive. A router detects the failure of a neighbor router if the neighbor router does not 
acknowledge the Hello message. When a router detects a failure, it generates a triggered 
LSA and the network is flooded with the LSA. Each router in the network recalculates its 
routing table and network converges quickly. 

The Hello protocol is also used to select a designated router (DR) and a 
back up DR for multi-access networks. Only the DR generates link state advertisements. 
The DR concept enables a reduction in the number of adjacencies required on a multi- 
access network. This in turn reduces the amount of routing protocol traffic and the size of 
the topological database. When a router has an LSA to propagate on the network, it 
transmits the LSA to multicast address of all DRs, to which both the DR and the backup 
DR listen. When the DR receives the LSA, the DR multicasts the LSA to all the other 
routers. 

The OSPF routing algorithm is based on Dijkstra's shortest path algorithm. 
It tries to find a path that is optimal with respect to a performance metric. The metrics 
can be latency, hop count, monetary cost, or combination of them. 

Another nice feature of the OSPF is that it allows multiple equal-cost 


routes to the same destination. Routers can choose different routes when forwarding 
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packets to the same destination. Traffic load in the network can be balanced with the use 


of multiple routes. [Ref.1] 


C. ATM PNNI (PRIVATE NETWORK-NETWORK INTERFACE) 


PNNI is a hierarchical routing protocol designed by the ATM Forum to support 
different hierarchies and topology aggregation. PNNI uses link state routing approach. 
PNNI supports many levels of hierarchical routing and allows routing based on quality of 
service [Ref.1]. Support of many levels is an important characteristic. In global routing a 
node has all the knowledge about the network. But often it is not feasible that a router 
maintains full information for all physical links. A node should maintain aggregated 
information about the network. Using this information, the node can find a sequence of 
partial paths at different abstraction levels. [Ref.3] 

Nodes at each level form a peer group. A peer group is expected to have between 
ten and a hundred nodes [Ref.1]. The nodes in the same peer group elect a peer group 
leader, which will function as Logical Group Node (LGN) representing the peer group as 
a single logical node in the next higher hierarchical level. PGL summarizes the topology 
information in the peer group and distributes it in the next higher level. This in turn 
reduces the amount of the topology database traffic. [Ref.4] 

LGNs at the same hierarchical level are connected by logical links and form 
another peer group. LGNs behave just like lower level nodes and synchronizes the LGN 
database with the neighboring LGNs. Then database is flooded in the logical peer group. 


PNNI in this way can support 100 different levels. [Ref.4] 
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PNNI has three basic protocols that define the dynamic distribution of routing 
information and the signaling, once the routing information is complete. They are Hello, 
Database Synchronization, and Peer Group Leader Selection. 

A node uses the Hello protocol to discover the neighbors and to maintain the 
connectivity to the neighbors. By Hello protocol a node learns the peer group id, node 
identity, and ATM address of its neighbor nodes. Hello protocol operates on a per link 
basis. As explained before, another use of the Hello Protocol is to detect the failure of a 
neighbor node and generate a triggered update accordingly. 

Once a node discovers that a neighbor node is in the same peer group it starts the 
process of synchronizing the topology database with each other. After the database 
synchronization process is complete, both nodes will have the same database. This 
information is then flooded through the entire peer group by PNNI Topology State 
Elements (PTSE) messages. ATM switches will have the same topology database after 
flooding. Each PTSE has an age. PTSE is valid during the age period. If the age of a 
PTSE expires, it will be removed from the topology database. A switch periodically 
sends update PTSEs to the others. When a new PTSE is received it will replace the old 
one. [Ref.4] 

PNNI uses source routing for connection reservation through the network. The 
first switch computes the entire path according to its topology database. The first switch 
can make a fairly good decision abut the path to follow since QoS parameters are kept in 


the database along with topology information. If a switch accepts the connection it passes 
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the request to the next one in the path. The use of source routing eliminates routing loops 


and speeds convergence in case of a link or node failure. [Ref.1] 
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III. LINK STATE ADVERTISEMENT MODEL 


Existing sontes protocols are mostly concerned with topology information, 
disregarding the availability of network resources. Thus they all have limitations in 
providing guaranteed or differentiated quality of service (QoS). To provide QoS, routing 
protocols should reserve network resources, such as link bandwidth, for flows or service 
classes. This will bring much more constraints to QoS routing algorithms compared to 
current shortest path algorithms. [Ref.5] 

Each SAAM server maintains a Path Information Base for its region and performs 
network management tasks based on this database. Each router periodically generates 
Link State Advertisement (LSA) packets and use a special control channel to send them 
to the server. The server processes received LSA packets to update its PIB and make 
necessary decisions. 

SAAM has an auto-configuration feature that establishes a control traffic channel 
between the server and the routers. The SAAM server periodically generates a Downward 
Configuration Message (DCM) to update the control channel. A router learns the way to 
reach to the server after receiving the DCM message. The router in turn multicasts the 
DCM message to all its neighbors, except for the one from which it has received the 
DCM. At the last step, the routers send the reachability information of the control 
channel back to the server using an Upward Configuration Message (UCM). Figure 3.1 


demonstrates the steps in the auto-configuration of the SAAM control channel. 
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——* Downward Configuration Message (DCM) “Pm the best way to server” 


Parent Notification Message (PN) “Pl use you as my next hop to server" 


*7——7 Upward Configuration Message (UCM) “The following routers can be reached 
by the server using this interface” 





Figure 3. 1. Auto-configuration and Building the Control Channel. 


A. REQUIREMENTS ANALYSIS 


1. Goals 


The main goal of LSA generation is to deliver timely link state data to the server. 


The major requirements are: 


e Keep the SAAM server up-to-date about available network resources. 


e Minimize the bandwidth requirements and processing overhead of Link State 


Advertisement packets. 


e Detect local interface failures and inform the server of such failures. 
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e Generate an extra LSA in case of a dramatic change in the performance of a 
particular type of traffic. For example, an LSA should be sent to the server 
when the queues for real-time flows build up rapidly because of a bug in the 


packet schedular. 


2. QoS Parameters 


The server maintains the current state of the network in a Path Information Base 
(PIB). The PIB contains data describing QoS capability of each service class as well. 
Specifically these QoS parameters are: 
e Utilization: The percentage of time that a service class is busy during a 
predefined time period. 
e Delay: The average time that a packet waits in queue before transmission. 
e Loss Rate: The percentage of packets that are dropped because of buffer 
overflow. 
A router must measure these parameters at each of its interfaces. The 


measurements from different interfaces are combined to form an LSA packet. 


B. QOS PARAMETERS OF SERVICE LEVEL PIPE 


Each service level pipe carries traffic for one of the service classes. Each service 
level pipe provides a particular level of network performance. Integrated services and 
differentiated services are each supported by one service level pipe. Another service level 
pipe is used for best effort traffic so that SAAM is backward compatible with legacy 


networks. 
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For a network management protocol like SAAM, control traffic management is a 
critical issue. To support real-time traffic, a network management protocol needs to 
check the status of the links, routers and flows at short intervals. This enables the 
network management protocol to adapt to changes in network conditions quickly and 
maintain the QoS support to real-time traffic flows. SAAM uses a separate service level 


pipe for control traffic which is assigned the highest priority. 


1. QoS Parameter Measurements 


Each service level is implemented as a queue. Currently these queues are first in 
first out (FIFO) queues. For each service level queue, performance metrics of interest 
are: service utilization, average packet delay, and packet loss rate. 

These metrics are measured at periods to find out the performance of each SLP. 
Each metric value is normalized with the previous measurement value. The general 


formula to calculate a metric is: 


Metric = a * CurrentMeasurement 4 (1— o) * Metric (3.1) 


a. Utilization 


The utilization of a service level queue is calculated by recording the total 
time that the pipe is busy, i.e. has at least one packet in a measurement period. In busy 
time calculation we are concerned with two transitions of the queue status: the transition 
from idle (empty) to busy (populated) and the one from busy to idle. Before a packet is 


queued, the status of the service level queue is checked. If the queue is empty then the 
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queue becomes busy and the busy timer is started as soon as the packet is enqueued. If 
the queue is not empty, meaning it is already busy, there is no need to adjust the timer. 
Likewise right after a packet is de-queued, the status of the service level queue is 
checked. If the queue becomes empty then the busy timer stops. If the queue status 
doesn’t change, the timer continues recording the busy time. 

Figure 3.2 illustrates the calculation of the utilization calculation of a 
service level queue. Initially the queue is empty. When a packet arrives at fj, the queue 
becomes busy, and the busy timer starts. When the service level queue becomes empty 
again at t,, busy timer stops, and the time difference t,-t, is added to the total busy 


time. 





Figure 3. 2. Utilization in Service Leve] Queue. 


The period that the utilization is calculated can end at two places. If the 
period ends at t, the total busy time is t,-t,, and in this case the busy start time is 
stamped with t, since the queue is still busy. The period may end at some place like €, 
where the queue is idle (empty). This time, the total busy time is the sum of previous busy 


times, t,-t, in this example. 
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After finding out the zotal busy time, first the calculated utilization is 
calculated by taking the percentage of the busy time in measurement period. Then the 
utilization of the SLP can be calculated as follows. 

The idea behind calculating the utility as the percentage of busy time at a 
specific period can be explained as follows: the SAAM server makes reservations along a 
path with associated QoS flow parameters specified by the requesting host application. 
Theoretically, if the bandwidth allocation is 40% at a service level queue then the service 
level queue is expected to be busy 40% of the time. If the service level queue is busy 


80% of the time, 80% of the service level queue bandwidth is used. 


b. Delay 


Delay is the waiting time a packet experiences in a service level queue. 
When the packet is en-queued, it is time stamped. And when it is de-queue, another time 
stamp is taken. The difference between de-queue time and en-queue time 1s the delay 
experienced by that packet. 

Reported delay is the average delay for the service level queue. To 
calculate average delay, queued packets are counted in a measurement period. The 
previous average delay is used to normalize the average delay. The average delay is 
calculated using the following formula. 


AverageDelay - [AverageDelay * (n - 1) - X]/n (3.2) 


In Equation 3.2, n is the packet count and X is the delay experienced by 


the packet. For example, at start of a measurement period the average delay is O. The first 
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packet is queued, and it leaves the queue 30 ms later. The average delay is (0*0 + 
30)/1=30 ms. The second packet comes and it leaves the queue 40 ms later. The reported 


delay is now: (30*(2-1)+40)/2 = 35 ms. 


c. Loss Rate 


For loss rate calculation, during each measurement period, the number of 
packets that have arrived and the number of packets that are dropped in the period are 
counted. When a packet is about to be en-queued the capacity of the queue is checked. If 
the packet can not be queued because the maximum queue size is reached, it is dropped. 
Every packet, including the dropped ones, increments the packet count. 

At the end of the measurement period, the percentage of the loss count is 
calculated first. This percentage is the observed loss rate for the period. Since history of 
the loss rate affects the current loss rate, normalization of the observed value with the 
previous loss rate is required. A normalization value A (0<=A<=1) is used to calculate 


the current loss rate. The formula to calculate the loss rate is as follows: 


LossRate = A * ObservedLossRate 4 (1 — A) * LossRate (3.3) 


2. LSA Data Collection at SLP 


Data collection is done at each queue. From the Figure 3.3, data is collected to 


calculate average delay, loss rate, and utilization of the queue. ` 
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. When a packet arrives, the packet 

When a packetıs en-queued, count is incremented IF the queue is 
itis ime stamped with the — Ver. че 
Euren nu ае - —. Tossconatis incremented 7 


“Е the queue becomes busy when 
у enqueueing a packet the busy timer 
When the packetis dequeued starts. 
another time stamp is taken *If the queue becomes idle when a 
that 1s used to calculate the packetis dequeued the busy timer 
average packet delay CS stops. 





Figure 3. 3. Collecting Data from SLP. 


Each data collection is done by a separate sub module. So different measurement 
periods can be used for metric calculations. 

Metric calculation modules wake up at the end of their measurement periods 
[Figure 3.3]. They calculate the their metrics using the collected data. Results of the 


calculation are stored to be presented to other modules when requested. 


К At the end of a measurement 
Loss rate is calculated by Pe aE 


countng the number of received РА edit calculate 
and dropped packets. ра 
the utilization. 





Figure 3. 4. Loss Rate and Utilization Modules. 
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3. Service Level Pipe State Advertisement 


The measured QoS parameters of a service level pipe are combined into a Service 
Level Pipe State Advertisement (SLP-SA) message. The SLP-SA message fields, and the 


number of bytes used to represent each field, are shown in Figure 3.4. 


SLP Number 


Figure 3. 5. Format of Service Level Pipe State Advertisement (SLP-SA). 


е SLP Number is the id of the service level pipe. Currently there are four service 
level pipes. They have ids ranging from 0 to 3. 

e Utilization is represented by a two-byte integer. Utilization is represented at a 
granularity of 0.1. The range of the values for this field is 0-1000. 0 means 
0% utilization, and 1000 meaning 100% utilization. For example, a value of 
654 means 65.4% utilization. 

e Delay is represented by a two-byte integer. The unit is milliseconds. The 
maximum delay is 2'° = 32768 ms. 

e Loss rate is represented by a two-byte integer. The valid values for loss rate 
are between O and 10000 with a granularity of 0.01. For example 7654 would 


mean 76.54% loss rate for that service level pipe. 


A module collects metric calculation data from a SLP, and combines them into a 
SLPLSA [Figure 3.6]. 
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When apacketis queued The calculation thread, activated 
or dequeued the related timing к by a imer, uses the collected 


data is collected data to calculate the utilization, 
| loss rate and delay. 





Figure 3. 6. Forming SLP-SA. 


C. INTERFACE STATE ADVERTISEMENT 

The link state of an interface must include states of all its service level pipes. So 
the Interface State Advertisement (InterfaceSA) is the combination of the SLP-SA of the 
service level pipes. InterfaceSA message parameters and the byte lengths are given in 
Figure 3.7. 


SA.lensth 


LSA Type Interface Id Bandwidth SLP-SAs 









Figure 3. 7. Interface State Advertisement (InterfaceSA). 


е LSA Type defines the type of this InterfaceSA. Three values are defined so far: 

% Type 0: This is an Update. The InterfaceSA carries information that will 
be used by the SAAM server to update the QoS parameters of the interface 
in the PIB. 

+ Type 1: This is an Add. This type is only used when the router has a new 
interface installed. The SAAM server adds interface and link state data to 


the PIB. 
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+ Type 2: This is a Remove. A router creates this type of LSA when one of 
its interfaces fails. The SAAM server needs this type to promptly delete 
those paths that use the failing interface frorn the PIB. Currently the flows 
using that interface are not rerouted. It is left as future work. 

e Interface id is the Ipv6Address of the interface. It is used by the SAAM server to 
identify the interface. 

e Bandwidth is the total bandwidth of the link associated with the interface in Kbps. 

е Number of SLPs specifies how many SLP-SAs are sent in the InterfaceSA. 


e SLP-SAs are concatenated at the end of the InterfaceSA. 


SLO SLI 512 313 SLO 511 512 513 
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Figure 3. 8. Forming Interface State Advertisement. 





Figure 3.8 depicts the forming of the InterfaceSA. Every interface has a module 
that periodically collects performance data (SLP-SA) from the SLPs. The data combine 


into an InterfaceSA that describes the performance of the interface. 
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D. LINKSTATE ADVERTISEMENT 


The link state of a router is combination of performance of its interfaces. So a 
Link State Advertisement (LSA) message is composed of InterfaceSAs. LSA message 


format is illustrated in Figure 3.9. 


Figure 3. 9. Link State Advertisement (LSA). 





e Message type distinguishes the message as an LSA. The type for LSA is 12. 
e Router id is an Ipv6Address. It is the biggest of the interface IP numbers of the router. 
The router id is selected as follows: 

+ Starting from the most significant byte, when one of the byte of one 
interface is bigger than that of any other interface, IP number of the 
interface is taken as the router id. Selection continues until the last bytes. 
Since each IP number is unique, one of the interface IP numbers will be 
bigger than the others. 

e Number of interfaces shows how many interfaces the router has. 

LSA messages are created periodically by a generation module. This module 
collects link states of each interface and combines them into an LSA message. Figure 
3.10 depicts the generation of LSA message. Routers piggyback their LSA messages to 


the UCM message, using the ability of the SAAM Message’s concatenation capability. 
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SLO SL1 SL2 513 SLO SL1 SL2 SL3 


. LSA Generation Module 





Figure 3. 10. Generation of Link State Advertisement. 


E. INTERFACE FAILURE 


A SAAM server makes flow reservations for real-time traffic. Real time traffic 
requires QoS support. The SAAM server needs to react to link failures in a very short 
time to meet the QoS requirements of the real time traffic flows. Interface failure is 
simulated by sending InterfaceFailure [Figure 3.11] message to a router. This message is 


not a part of the SAAM. It is used just for simulation purposes. 


ee | 
IPv6Address 


Figure 3. 11. InterfaceFailure Message Format. 


e Message type value is 127. 


e [Pv6Address is the address of the failing interface 


When a router receives an InterfaceFailure message, it finds the interface and 
changes the status to down. Interface failure is detected by the LSA generation module. 
The LSA generation module always checks the status of the interfaces while creating 
LSA messages. When it detects an interface failure, it will report to the server by a 
triggered LSA. The server, after receiving the triggered LSA, updates its PIB by 
removing the paths that contain a SLP of the failed interface. The server should reroute 


the flows using those paths. Rerouting of flows is left as future work. 
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IV. IMPLEMENTATION 


An implementation of the LSA mechanism has been carried out with the Java 
programming language. This implementation is a part of the most recent SAAM system 
prototype. The code is written in a modular way. By making the code modular, it was 
possible to debug and verify a small number of functionalities at a time. For efficiency, 


independent tasks are performed with separate threads whenever possible. 


A. LSA GENERATION 


Every node (router or server) in aSAAM region performs LSA generation tasks. 
The server has the additional responsibility of processing LSA messages. The following 


Java classes are used for LSA generation: 


1. PriorityQueue 


PriorityQueue replaces the previous queue implementation which does not have 
the packet performance data collecting primitives. PriorityQueue has built-in data 
collecting functionalities. PriorityQueue has a double-linked list based data structure. It 
has all the functionalities of a first-in-first-out queue. Figure 4.1 shows the methods of 
PriorityQueue. 

PriorityQueue keeps track of the number of packets currently queued by using the 
size variable. The size of the queue can grow to maximum queue size, a variable used to 
define capability of the queue. If no parameter is given, the default constructor creates an 


instance with the default maximum size which is 200. Both constructors initialize those 
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variables used to calculate the average packet delay, service level utilization, and packet 
loss rate. 

Each service level pipe is implemented by a PriorityQueue object. Service level 
queues collect service level performance data and perform calculations to determine the 
value of each metric. 

When a packet is queued, size is compared with the maximum queue size. If 
maximum queue size is reached, the packet is dropped, and the loss count and packet 
count are incremented. Otherwise, just the packet count and the queue size are 
incremented. 

If the queue was empty before a packet is queued, it becomes busy. The current 
time is recorded as the busy start time. A Queueltem object is created that holds the 
packet and the arrival time stamp of the packet. This Queueltem is inserted to the end of 
the queue. 

PriorityQueue 
PriorityQueue() 
calcDelay() 
calcLossRate() 
calcUtility() 
dequeue() 
enqueue() 
getCalcTime() 
getDelay() 
getLossRate() 
getMax QueueSize() 


getSize() 
getUtilization() 





Figure 4. 1. saam.util.PriorityQueue 
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While a packet is dequeued, the queueing delay of the packet is calculated. The 
value is the difference between the arrival time and the departure time of the packet. 
Packet queueing delays are used to calculate the average packet delay. 

To find out the service level utilization, the total busy time in the current 
measurement interval must be determined. The start and end times of each busy period 
are recorded to find out the length of the busy period. A busy period starts when a packet 
is put into an empty queue. The busy period ends when a service level queue becomes 
empty when a packet is dequeued. The sum of the busy periods gives the total busy time 
in a measurement period. 

Service level utilization is calculated by using the total busy time. A timer 
periodically creates an action sets the flag, a boolean variable, that starts the service level 
utilization calculation. A separate thread performs the utilization calculation, and then 
lowers the flag and enters a wait state. For utilization calculation details please refer to 
Chapter 3. 

A similar approach is taken for the packet loss rate calculation. A separate thread 
calculates the loss rate of the service level queue. A second timer periodically invokes the 
loss rate thread. After invocation, thread calculates the loss rate by computing the 
percentage of packets that are dropped in the current period and normalizing the result by 


the previous measurement interval. 
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2. Service Level Pipe State Advertisement (SLP-SA) 


SLP-SA is the class that manages the state of performance of a service level pipe 
[Figure 4.2]. Performance data taken from a service level pipe together with the SLP 
number are combined into an SLP-SA. SLP-SA has four data members: SLP Number, 
service level utilization, packet delay, and packet loss rate. One constructor of the class 
takes three parameters, one for each of these values, and creates an SLP-SA. The other 
constructor takes these data in a byte array and constructs the SLP-SA by extracting data 


members from the byte array. 


SLP-SA 
SLPLSAO 
getBytes() 
getDelay() 


getLossRate() 
getSLPnum() 

getUtiliztion() 
toString() 





Figure 4. 2. saam.message.SLP-SA 


For each data member, there 1s a get method to retrieve the value. The values of 


all data members can be put into a byte array and retrieved using the getBytes() method. 


3. Interface State Advertisement (InterfaceSA) 


InterfaceSA is the class that manages the performance status of the interface 
[Figure 4.3]. It is created by the LinkStateMonitor of each interface. It has three 


constructors. The first one takes a byte array as parameter and constructs the class by 
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extracting all data members from the array. The second takes an /Pv6Address and an 
integer number for the bandwidth of the interface. The third takes an ГРубАдагезз, an 
integer bandwidth, and a byte for type of InterfaceSA. The InterfaceSA packet format is 
shown in Figure 3.6. 

InterfaceSA can be one of three types: remove, add, and update. Default type is 
update. When an interface is to be added to the PIB, an InterfaceSA of type add is 
created. Likewise when an interface is to be removed an InterafceSA of type remove is 
created. 

SLP-SAs can be added to an InterfaceSA either one by one or by a vector of SLP- 
SAs. Each added SLP-SA increments the SlpNumber value, the variable used to keep 


track of the total number of SLP-Sas in an InterfaceSA. 


InterfaceSA 
InterfaceLSA() 
getBandwidth() 
getBytes() 
getIP() 
гей заТуре() 
getNumOfSips() 
getSLPs() 
insertSLP() 
setLsaType() 


tnStrinn/\ 
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Figure 4. 3. saam.message.InterfaceSA 


All data members of InterfaceSA can be retrieved using the gerBytes() method. 
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4. LinkStateMonitor 
LinkStateMonitor is the class, that generates InterfaceSA messages. Each 
interface has a LinkStateMonitor that monitors the performance of the service level pipes 


of the interface. 


LinkStateMonitor 
LinkStateMonitor() 
generateInterfaceLS A() 
getLSA() 


getStatus() 
toString() 





Figure 4. 4. saam.residentagent.LinkStatemonitor 


LinkStateMonitor generates an InterfaceSA when there is a UCM packet ready to 
be sent to the server or when the LsaGenerator requests one. It uses the 
generatelnterfaceLSA() method and reads the SLP-SA of each service level pipe. It then 


passes the InterfaceLSA to LsaGenerator. 


5. LinkStateA dvertisement 


LinkStateAdvertisement is the class that manages the performance status of a 


router. LinkStateAdvertisement extends saam.message.Message and its message type is 


12. 
LinkStateAdvertisement has two constructors. The first one takes the /Pv6Address 


router id, which is the biggest interface address of the router. The second constructor 
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creates a byte array representation of the data. It is used by the server to reconstruct the 


LinkStateAdvertisement packet from the byte array. 


Message LinkStateAdvertisement 
Message) 
getBytes() 
getType() 
length() 


LinkStateAdvertisement() 
getBytes() 

getLSAs() 

getMyIPv6() 
getnumberOfInterfaces() 
insertInterfaceLS A() 
length() 

toString() 


toString() 





Figure 4. 5. saam.message.LinkStateAdvertisement 


LinkStateAdvertisement contains the InterfaceSAs of all the interfaces of a router. 
It keeps them in а vector. InterfaceSA messages can be added to a 
LinkStateAdvertisement message individually or together as a vector. When an 
InterfaceSA is added numOfinterface, the variable used to keep track of the total number 
of InterfaceSA messages in a LinkStateAdvertisement, is updated. The numOfinterface 
variable is used when constructing a LinkStateAdvertisement message from a byte array 


by the server. 


6. LsaGenerator 


LsaGenerator, as its name implies, is the class that generates 


LinkStateAdvertisement messages. It is instantiated by ControlExecutive of a router. 
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LsaGenerator starts generating LSAs after the interfaces are initialized by a DemoHello 
message. 

LsaGenerator has two constructors. One of them takes ControlExecutive as a 
parameter. It uses the default LSA generation interval, which is ten seconds. The other 
takes ControlExecutive and an integer for LSA generation interval. 

A tümer periodically invokes LsaGenerator by setting a boolean flag. 


LsaGenerator generates an LSA by calling the performLSACycle() method. 


java.lang.Runnable LsaGenerator 


e Run() LsaGenerator() 


checkIdChange() 
checkInterface() 
decideRouterld() 
generateExtraLSA() 
getGenerationTime() 
getRouterld() 
performLSACycle() 
setGenerationTime() 
startAction() 
startInterfaceCheck() 
toString() 


saam.event.SaamListener 
e  receiveEvent() 


saam.event.SaamTalker 


saam.message.MessageProcessor 
e  getMessageTypes() 
e  processMessage() 





Figure 4. 6. saam.residentagent.router.LsaGenerator 


While generating an LSA, LsaGenerator first checks the status of each interface. 


If the interface is up, it takes an InterfaceSA from the interface. It combines every 
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InterfaceSA and adds other LSA fields to form an LSA message. The LSA message is 
passed to AutoControlExecutive to be concatenated to a UCM message. When 
LsaGenerator discovers that an interface is down, it creates two LSA messages of the 
remove type for the down interface. These LSA messages are sent to the primary and 
backup servers using sendLSA() method of the ControlExecutive. 

The reason to send two consecutive LSAs is to be sure that the server receives at 
least one of the LSAs. Since the down interface could be the one that was used to reach 
to the server. If the LSA message is just sent once, it may not reach the server. By auto- 
configuration, the SAAM control channel is refreshed at every cycle. In the next cycle, 
router will learn the new way to reach the server. So the server will receive the second 
LSA even if the first one got lost. 

Another thread is used in the LsaGenerator class to check the interfaces. The 
check thread is active at every two seconds. After each check it goes to wait state. There 
is a second timer, which triggers the checks. This timer periodically raises a boolean flag 
to wake up the check thread. The check thread examines the status of each interface. If 
no interface is down, it lowers the flag and goes back to the wait state. If it detects a 
down interface, it generates and sends two consecutive LSA messages as described above. 


Therefore, an interface failure will be detected in at most two seconds. 
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B. LSA PROCESSING 


1. ServerAgent 


The ServerAgent class is the receiver of all server-bound messages. It uses a 
Server object to process these messages. In the previous implementation, ServerAgent 
would receive Hello messages from all the routers in the region. Server then would use 
these Hello messages to build up the PIB. 

With the addition of Link State Advertisement model, the topology information is 
carried by LSA messages. Since the need for Hello messages is gone, the portion of code 


handling Hello messages is removed from processMessage() method. 


2. Server 


Server builds up the PIB and maintains it by processing LSA messages received 
from routers in the region. 

A new table, called RouterLookUp, is created to map the new IPvóAddress router 
id with the integer router id used by the previous implementation. This table provides a 
link between the two implementations. 


The following methods are added to the Server class: 


a. void processLSA(LinkStateAdvertisement Isa) 


LSA messages received by ServerAgent are passed to this method for 
processing. This method first extracts the Ipv6Address router id from the LSA message. 


Using the RouterLookUp table it tries to learn the integer id of the router. 
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If the ГРубАдагезз router id is not in the lookup table, the server will try 
finding the integer id by using all interface addresses learned from the LSA message. It 
will send these addresses to the doesRouterExist() method. The doesRouterExist() 
method will return an integer value. A return value of ROUTERNOTINPIB indicates that 
the server has received an LSA from a router for the first time and the newRouter flag is 
set to true. A new integer router id is assigned to this router and RouterLookUp table is 
updated. 

Using the LinkStateAdvertisement’s getLSAs() method InterfaceSA 
messages are retrieved in a vector. Starting from the first element in the vector, the server 
processes each InterfaceSA messages. 

If the type of the InterfaceSA is add, the interface is added to the PIB. 
With the addition of a new interface, the router id of a router may change. If there is id 
change, the RouterLookUp table will be updated. After adding a interface, the link state 
data is updated and findAllPossiblePaths() method is used to add new paths to the paths 
table. If the InterfaceSA type is update, the updatePIB() method is called to update the 
related interface state data in the PIB. If the type is remove, the server checks if the 
interface is in the PIB. If it is not in the PIB, nothing will be done. If it is in the PIB, the 
removelnterfaceFromPIB() method will be called to remove the interface and those paths 
using that interface. If the removed interface address is the router id of a router a new 
router id is calculated for that router. 

When a new router is added to the PIB, all paths are updated by the 


findAllPossiblePaths() and the effective QoS is calculated for all paths. 
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b. void checkAndAdd(int nodeld, InterfaceSA curLsa) 


To add a new interface this method is called. This method checks if the 
node with nodeld has an interface with the IPv6Address specified by curLsa. If the 
interface is not already in the PIB, it is added to the PIB. Also all SLPs of the interface 


are added to the PIB. The link state data of the interface initialized based on curLsa. 


c. void updatePIB(int nodeld, InterfaceSA curLsa) 


If the InterfaceSA sent by a router is an update, it is sent to this method. 
All SLP-SAs are taken from the curLsa as a vector. The node to be updated is found from 


the nodes table using nodeld and the interface is found from the /Pv6Address of curLsa. 


d. void removelnterfaceFromPIB(int nodeld,InterfaceLSA curLsa) 


This method removes an interface and those paths using a SLP of the 
interface. First it calls removePathsTraversingInterface() that removes the paths using 
the IPvóAddress address of the interface as key. Then it calls removeLinkFromPIB() that 
removes the link associated with the interface. Finally it calls the 


removelnterfaceFromNode() method to remove the interface from the nodes table. 


e. void removePathsTraversingInterface(IPv6A ddress ip) 


This method deletes all paths that use interface. By using the 
getAllPathldsThatTraverseSLP() method, it gets the ids of paths to be removed in a 


vector and deletes all paths from the paths hash table. 


48 


f. void removeLinkFromPIB(IPv6Address ip) 


After deleting all paths traversing interface, this method is called to 


remove the associated link from the links hash table. 


g. void removeInterface FromNode(IPv6Address ip) 


This method deletes the interface ip from the nodes hash table. 


В. void checkRouterlId(IPv6Address routerId,Vector iLsa Vector) 


If one of the InterfaceL'SA messages is of type remove or add, this method 
is called. It checks if the router id requires change or not. It uses the same algorithm to 
calculate the router id as the routers so that the router ids are same at the router and the 
server. New LSAs received from that router will have this new router id because the 
same procedure was done at the router, too. Currently the addition of an interface to a 


running router is not implemented yet. 


C. SIMULATION OF INTERFACE FAILURE 


When an interface fails, server should know the failure and take necessary steps 
for the affected flows. Routers inform the server about the failure of an interface with 
LSA messages. 

The interface that failed may be the one used to reach the server. In this case, if 
the LSA is sent once, it may not reach the server. To make sure that server receives the 


failure information, the LSA carrying this information is sent a second time. Since auto- 
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configuration will refresh the control channel at the next configuration cycle, router will 
learn the new way to reach the server bypassing the failed interface. 

To simulate the failure of an interface, an InterfaceFailure message [Figure 4.7] is 
sent from the DemoStation to a router. This message has an /Pv6Address as data member, 


which is the address of the failed interface. 


saam.message.Message InterfaceFailure 
e Message() InterfaceFailure() 
getBytes() getB ytes() 
getType() getIP() 


length() length) 
toString() 





Figure 4. 7. saam.message.InterfaceFailure 


The message processor of the failure message is ControlExecutive. When 
ControlExecutive receives an InterfaceFailure message, it compares the IPv6Address of 
each interface with the address in the message. If ControlExecutive finds a match, it sets 
the interface status variable of that interface to false, which means the interface is down. 
The status of an interface is checked every time a packet enters the interface. If the status 
is down, the packet along with those already in queue are dropped. 

The failure of the interface will be detected by LsaGenerator. A part of the 


LsaGenerator checks the status of the interfaces in short periods. When it detects that an 
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interface is down, it creates a LinkStateAdvertisement and sends it to every server in the 


region by using the sendLSA() method of the ControlExecutive. 


5] 
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52 


V. INTEGRATION AND TESTS 


By the completion of the auto-configuration of control channel, routers in a 
SAAM region send LSA messages by concatenating them to UCM (Upward 
Configuration Messages). Each server learns its children and builds up its PIB by the 


concatenated LSA messages. 


A. INTEGRATION 


Servers and routers have some differences concerning UCM and LSA messages. 
A server sends LSA messages to itself and to other servers. It processes both LSA and 
UCM messages. On the other hand, routers only process UCM message of a child, from 
which a PN (Parent Notification Message) has arrived. To meet the different requirements 
of servers and routers, differentiation is made at PacketFactory, which is the common 
place for both message types. 

Each router creates a ServerInformation class for each server, where it keeps track 
of the information about the server. ServerInformation class is chosen to store the 
concatenated LSA messages on the way to a server. 

Figure 5.1 illustrates the UCM message handling at a router. When a UCM 
message group, UCM message with concatenated LSA messages, arrives to a router, it is 
forwarded from PacketFactory to AutoControlExecutive. AutoControlExecutive extracts 
the UCM message from the message group, and learns the flow id of the server, which 
the packet is destined for. Using the flow id of the server as key, associated 


ServerInformation is learned. The concatenated LSA messages and the number of LSA 


ЭЗ 


messages are passed to the ServerInformation of the server. AutoControlExecutive 


continues with the processing of the UCM message. 


UCM message passed from PacketFactory 
toAutoControlExecutive, 
FT 


LSA messages are stored 
to the server information 


Serv erlnformation 





Figure 5. 1. UCM Arrival and Storing to ServerInformation. 


Router prepares its UCM message by using the received UCM messages. When 
the router UCM message is ready, LSA message of the router is concatenated to the 
message. Received LSA messages are taken from the Serverlnformation and 
concatenated to the UCM message group. While concatenating messages, number of 
messages is updated. 

The server is the processor of the UCM messages. When a UCM message group 
arrives to a server, messages are extracted from the group and processed individually 
depending on the message type. PacketFactory check if it is a server, when it receives a 


UCM message by calling the ControlExecutive getIsServer() method. 
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B. TESTS 


LSA concept is tested in a three-computer test network. Figure 5.2 depicts the 
topology of the test network. All computers have 166 MHz CPU speed and connected by 


a 10 MBPS Ethernet LAN. 


Kati? 
131.120.9.76 





Figure 5. 2. Test Topology. 

In the current implementation the PIB is built up from the scratch when the server 
learns that there is a new router. This takes extra time and inefficient. Another point is 
the emulated environment. Ipv6 packets are sent using an emulated network stack. 
Layers of the network are simulated in software, which is another reason why the PIB 
build up is slow. First element added to the PIB is the server itself. The server sends 
LSA messages to itself. Routers are added to the PIB when the server receives the LSA 
messages that are concatenated to a UCM message. 


Table 1 shows the times of the PIB build up when GUI comments are enabled: 


a a на | 











Katil(Server) 75 milliseconds 90 milliseconds 
Дт 


Table 1. PIB Build Times. 
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These results improve at a certain level when the GUI comments are disabled. 
But the overall performance still lacks the speed and efficiency. Table 2 shows the test 


results when the GUI comments are disabled. 


|_____________-_Гожен _____ реч __| 
Katil(Server) 60 milliseconds 80 milliseconds 





Table 2. PIB Build Without GUI Comments. 


56 


VI. CONCLUSIONS 


A. SUMMARY 

In this thesis I implemented a model for generating and processing Link State 
Advertisements in the SAAM architecture. I implemented the model in the Java 
programming language. I debugged and improved the old threading model of the 
previous SAAM prototype. Further, I integrated my new design to those of four other 
colleagues. I implemented each sub-model in a separate thread for performance and 
parallelism. This work substantially improved and added to the overall functionality of 


SAAM. 


B. LESSONS LEARNED 


The main focus of this study is to develop a model that delivers link state 
performance data of the routers to the server in the SAAM architecture in a timely 
manner. Integrating the model with the previous version of SAAM took more time than 
the development of the model. In most cases, a new functionality can be implemented as 
a separate module to make the design more modular. But some code modifications and 
additions to existing modules were inevitable. The biggest difficulty came from the lack 
of knowledge about of the Java programming language the thread support. Sometimes a 
thread synchronization problem took a week of study to debug and correct. 

Another lesson is the need to coordinate between the team members of the current 


development group. Each functionality of SAAM is developed as a thesis study by one of 


S 


the team members. The modifications and improvements made one member impact the 
work of other team members. This taught us the need to develop a software development 


paradigm for developing a large system like SAAM. 


C. FUTURE WORK 


1. Improving the PIB Path Processing 


Currently the PIB is built from scratch when the server learns a new router in the 
region. A more efficient algorithm could be deployed that adds new paths to the current 


PIB, rather than rebuilding the whole PIB. 


2. Rerouting of the Flows if an Interface Fails 


When an interface fails, the SAAM server should reroute the flows that are 
affected. The server should also update the PIB by deactivating the paths that include a 


SLP of the failed interface. This feature is currently not available. 


3. Securing SAAM 


SAAM server is the central authority managing the region. It must be secured to 
prevent hackers from disrupting network services. Control traffic must be authenticated to 


prevent illegal alterations to PIB by malicious attacks. 
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APPENDIX A. PRIORITYQUEUE CLASS SOURCE CODE 


package saam.util; 


import javax.swing.Timer; 

import java.awt.event.ActionListener; 
import java.awt.event.ActionEvent; 
import java.text.DecimalFormat; 


import saam.message.SLPLSA; 


/** 
* this class will represent a priority queue for the saam packets 
* smaller the value higher the priority 
m 

public class PriorityQueue extends FIFOQueue( 


/** 
* default size of the queue 
Ху 
public static final int DEFAULT_SIZE=200; 


public static final byte MAX_UTIL = 100; 
public static final short MAX DELAY - Short.MAX VALUE; 


public static final short MAX, LOSS - 10000; 


/** 
* int representing milliseconds to recalculate the values of 
lossRate,delay 
* and utilization - 5 minutes 
x 
public static final int TIME_TO_RECALCULATE=2000; 


public static final double ALFA_FOR_LOSSRATE = 0.7d; 
private int calculationTime; 
/** 
* max size if the queue 
* 
EN ie int maxSize; 
private long packetCount; 
private long lossCount; 
private Timer timer; 
private double alfa; 
private double currentLossRate=0.0d; 


private boolean lossStart = false; 
private Object lossLock=new Object (); 
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private double previousLossRate=0.0d; 
private double reportRate=0.0d; 
private long currentPacketDelay; 
private double currentDelayAve; 
private double previousDelayAve; 


private double utility=0.0d; 

private double preUtility=0.0d; 

private long busyTime-0; 

private long busyStartTime; 

private double utilRatio = 0.8d; 

public static final int DEF_UTIL_CALC_PERIOD=25000; 
int utilPeriod = DEF_UTIL_CALC_PERIOD; 

private Timer utilTimer; 

private boolean utilStart-false; 


private Object theLock=new Object (); 
private Object utilityLock = new Object (); 


/** 
* current size of the queue 
7 

private int size; 


private Queueltem first, , last, current; 


/** 

* parameterless constructor of the class 

a 
public PriorityQueue() ( 

maxSize = this.DEFAULT, SIZE; 

size - 0; 

packetCount=0; 

lossCount=0; 

first = last = current = null; 
calculationTime = TIME_TO_RECALCULATE; 


Runnable lossRunner = new Runnable() { 
public мола rum 
while (true) { 
сЕ 
synchronized(lossLock) { 
while(!lossStart) { 
lossLock.wait (); 


} 


}catch (InterruptedException ie) { 
System.err.println(ie); 


calcLossRate(); 


)//while 
) 
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a 
Thread lossThread = new Thread(lossRunner, "LoosRate"); 
lossThread.start(); 


timer = new Timer(calculationTime,new ActionListener()( 
public void actionPerformed(ActionEvent event) { 
synchronized (lossLock) { 
lossStart = true; 
lossLock.notify(); 
} 
} 
DE 


timer.start(); 


Runnable utilRunner = new Runnable() { 
public void run(){ 
while (true) { 
ery 
synchronized (utilityLock) { 
while (!utilStart) { 
utilityLock.wait(); 

} 


}catch(InterruptedException ie) { 
System.err.println(ie); 
} 
сай сен ЕУ)? 
}//while 
} 
ps 
Thread utilThread = new Thread(utilRunner," Utilization"); 
utilThread.start(); 
utilTimer=new Timer (utilPeriod,new ActionListener () { 
public void actionPerformed(ActionEvent event) { 
synchronized (utilityLock) { 
utilstart = true; 
utıjlıtylock.noctify(); 
} 
} 
ГІ; 
utilTimer.start(); 
alfa = ALFA_FOR_LOSSRATE; 
}//end constructor 


/** 
* parameter constructor 
* Qparam queuesize int size of the queue 
%7 
public PriorityQueue (int queuesize) { 
maxSize = queuesize; 
size=0; 
packetCount=0; 
lossCount=0; 
calculationTime = TIME_TO_RECALCULATE; 
timer = new Timer (calculationTime,new ActionListener(){ 
public void actionPerformed (ActionEvent event) { 
calcLossRate(); 
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} 
E 
timer.start(); 
utilTimer=new Timer (utilPeriod,new ActionListener()( 
public void actionPerformed(ActionEvent event) { 
calcUtiliey (es 
} 
12% 
utilTimer.start(); 
alfa - ALFA FOR, LOSSRATE; 
)//end constructor 


private void calcUtility() { 
if(!isEmpty()){ //there are packets in the queue 
long currentTime = System.currentTimeMillis(); 
busyTime = busyTime+(currentTime -busyStartTime) ; 
busyStartTime = currentTime; 
} 


if (busyTime>utilPeriod) { 
busyTime = utilPeriod; 


} 
utility = (busyTime/ (double)utilPeriod) *100; 
пе у = M(utilRatio0* utility) + (1-utilRatio)*preUtility; 


Preveplity = utility: 
busyTime=0; 
DecimalFormat df = new DecimalFormat ("##.###"); 
String edtoer—dt., format (ULI ty) ; 
//System.out.print1n("Utiliy is '"rdfstr); 
utilStart = false; 

} 


public int getCalcTime() { 
return calculationTime; 


} 


public void setCalcTime (int newTime) { 
//do not allow a time smaller than 1 sec 
if (newTime<1000) { 
System.out.println("The smallest value is 1 sec.(1000)."); 
return; 
) 
calculationTime = newTime; 
} 


public double getAlfa()( 
return alfa; 
} 


public void setAlfa (double пемА1 Ға) { 
//alfa is a value between 0 and 1 
if(newAlfa«0.0 || newAlfa>1.0) { 
System.out.println("New alfa value must be between 0 and 1. Alfa 
is not set."); 
return; 
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} 


alfa = newAlfa; 
} 


/** 
* queuees a new packet depending on the priority of the packet 
* Qparam packet Object 
* (param priority int priority of the 
*/ 
public synchronized void enqueue(Object packetArray) { 


//if size exeeds the maxSize 
//we need to drop the packet since there is no place in the queue 
1f((size+1)>maxSize) { 
lossCount++; 
packetCount++; 
return; 
} 
if(isEmpty()){ 
//queue was idle 
busyStartTime-System.currentTimeMillis(); 
) 


size++; 
packetCount++; 


byte [] packet = (byte[]) packetArray; 


long ts-System.currentTimeMillis(); 
QueueItem newlItem-new QueueItem(packet,ts); 
if (first==null) { 
first = last = newlItenm; 
} 
else{ 
current=first; 
while (current.next'!=null){ 
current = current ..next; 
}//end while 
current .next=newItem; 
newItem.previous=current; 
last=newItem; 
}//end else 


)//end enqueue() 


"fo | 
* removes the highest priority packet from the queue 
* @return Object 
x 

public synchronized Object dequeue() { 


tee reste таа а ри 
calcDelay(); 
size--; 
if(isEmpty()){ 
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busyTime = busyTime +(System.currentTimeMillis()- 
busyStartTime); 
System.out.println("Total busy time is "+busyTime); 


} 


current = first; 
if(first.next==null){//item is also the last 
first. = laste- null; 
} 
е15е( 
first=current .next; 
first.previous=null; 
} 
return current .data; 
}//end if 
return null; 


}//end method dequeue () 


private void calcLossRate()( 
currentLossRate - 0.0; 
if (packetCount==0) { 
packetCount=1; 


} 
currentLossRate = (lossCount/ (double) packetCount) *100; 


lossCount = 0; 


packetCount = 0; 
reportRate = (alfa*currentLossRate) + (l-alfa) *previousLossRate; 


previousLossRate = currentLossRate; 
lossStart=false; 


} 


ужк 

* returns the loss rate as percentage 

* @return int 

*/ 
public short getLossRate () { 

return (short) (reportRate/SLPLSA.LOOSRATE_UNIT); 
)//end method getLossRate() 


/** 


* Qreturn Object 
x 
public synchronized Object peek() { 
calcDelay(); 
return first.data; 
}//end method peek() 


private void calcDelay() { 
long outTs = System.currentTimeMillis(); 
currentPacketDelay = outTs - first.timeStamp; 
currentDelayAve = ((previousDelayAve* (packetCount-1) )+ 
currentPacketDelay)/packetCount; 
) 
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* returns the Object the first packet in the queue - highest priority 


/** 
* returns the delay amount of the packet in the queue 
* (return int 
7 
public short getDelay() { 
return (short) currentDelayAve; 
)//end method getDelay() 


/** 
* returns the size of the queue 
* @return int 
* / 
public int getSize(){ 
return size; 
}//end mthod getSize() 


/** 
* returns true if the queue is empty 
* Qreturn boolean 
zi 
public boolean isEmpty()í( 
return size==0; 
}//end isEmpty () 


/** 
* returns the int utilization of the queue 
* Qreturn int 
EJ 
public synchronized byte getUtilization() { 
return (byte) (utility/SLPLSA.UTIL_UNIT) ; 
}//end method getUtilization() 


/** 
* returns the int max size of the queue 
* Qreturn int 
ER 
public synchronized int getMaxQueueSize()( 
return this.maxSize; 
)//end method getMaxQueueSize() 


^к 

* changes the max queue size 

* @param newSize int size to be set 

Ж 
public synchronized void setQueueSize (int newSize)({ 

//it should atleast be 1 

if (newSize<1) { 

return; 
} 
this.maxSize=newSize; 
)//end method setQueueSize() 


/** 

* return a string representation of the queue 
* Qreturn String 

*/ 
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public synchronized String toString(){ 
return "Queue "; 
)//end method toString() 


)//end class priorityqueue 


class Queueltem{ 
public Object data; 
public QueueItem next,previous; 
public long timeStamp; 


public Queueltem(Object packet, long timeStamp) { 
data=packet; 
this. timeStamp=timeStamp; 
ПехЕ- пишат; 
previous=null; 
)//end constructor 
}//end class Queueltem 


//end file PriorityQueue.java 
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APPENDIX B. LINKSTATEMONITOR CLASS SOURCE CODE 


package saam.residentagent; 


import 
import 
import 
import 
import 


import 
import 
import 
import 
import 
import 
import 


public 


private 
private 
private 
private 
private 
private 
private 
private 


java.util.TooManyListenersException; 
java.util.Vector; 

javax.swing.Timer; 
java.awt.event.ActionListener; 
java.awt.event.ActionEvent; 


saam.router.*; 

saam.event.*; 

saam.util.*; 

saam.control.*; 

saam.net.*; 

saam.message.*; 
saam.residentagent.router.LsaGenerator; 


class LinkStateMonitor { 


SAAMRouterGui gui; 

Interface parent; 

int instance; 
ControlExecutive control; 
boolean firstTime-true; 
Object theLock - new Object(); 
boolean started - false; 
InterfaceLSA myLSA; 


//I plan to use this boolean varialble to simulate the link UP or DOWN 


state 


private boolean interfaceState - 


true; 


public LinkStateMonitor(Interface parent,ControlExecutive controller) { 
this.parent-parent; 


instance = parent.getInstanceNumber (); 
//gui = new SAAMRouterGui ("Link State Monitor "+instance); 
control = controller; 


7 Гепа constructor 


public InterfaceLSA getLSA() { 
generatelnterfaceLSA(); 
return myLSA; 


} 


N 


* creates the interfaceLSA for this interface and send it to LSA 
generator 
* @return void 


n 
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private synchronized void generateInterfaceLSA()( 


//gui.sendText ("genereting interface lsa"); 
//first append the header section of the InterfaceLSA 
InterfaceID id = parent.getID(); 


if(firstTime) { 
myLSA = new 
InterfaceLSA(id.getIPv6(),id.getBandwidth(),InterfaceLSA.ADD) ; 
firstTime = false; 
} 
else{ 
myLSA = new InterfaceLSA (id.getIPv6() ,id.getBandwidth()); 


} 
Vector slpVector = new Vector(); 


//for every Service level queue we need to know the servicelevel 


data 
for(int i=Interface.SERVICE_LEVEL_QUEUE_START_INDEX; 


i<Interface.numberOfQueuesOnThisInterface; i++) { 


PriorityQueue sl=null; 
try{ 
sl = (PriorityQueue) parent.getQueue(i); 
}catch(Exception e) { 
//gui.sendText (e.toString()); 
} 


short delay = sl.getDelay(); 
short lossRate = sl.getLossRate(); 
byte utilization = sl.getUtilization(); 


SLPLSA sl1LSA - new SLPLSA( (byte) (i-1),utilization, delay, lossRate) ; 
slpVector.add(s1LSA) ; 
}//end for 


myLSA.insertSLP(slpVector) ; 
started = false; 
)//end method generateInterfaceLSA() 
public boolean getStatus() { 
return interfaceState; 
} 
public String toString ({) { 


return ("LinkStateMonitor") ; 


} 
} 
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APPENDIX C. LSAGENERATOR CLASS SOURCE CODE 


package saam.residentagent.router; 


import 
import 
import 
import 
import 
import 


import 
import 
import 
import 
import 
import 
import 


public 


java.net.*; 

java.util.Vector; 
java.util.Enumeration; 
javax.swing.Timer; 
java.awt.event.ActionListener; 
java.awt.event.ActionEvent; 


Saam.residentagent.*; 
saam.router.*; 
saam.event.*; 
saam.util.*; 
saam.control.*; 
saam.net.*; 
saam.message.*; 


class LsaGenerator implements SaamListener, 


SaamTalker,MessageProcessor, 


ActionListener, Runnable{ 


//time between two LSA generations 


public static final int LSA_PERIOD = 


/** 


10000; 


* gui of the LSA Generator 


"f 


private SAAMRouterGui gui; 


/** 


* reference to the ControlExecutive 


Е 


private ControlExecutive controlExec; 


/** 


* id of the router 


27 


private IPv6Address routerId = new IPv6Address(); 


private IPv6Address oldId; 


ГЕК 


* numOfInterfaces 


ЕА 


private int numberOfInterfaces-0; 


pr 


* 


Е 


private int packetsReceived, packetsSent; 


/** 
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* source and destination ports 


2 


private short sourcePort,destPort; 


/** 


* vector that holds InterfaceIDs 


5 
private 


/** 


Vector interfaceIDs; 


* @serial 


“7 
private 
(3; 
private 
private 
private 
private 
private 
private 
private 


private 


private 


String[] messageTypes = 


Object myLock = new Object (); 
Timer timer; 

int timeBetweenLSAGenerations; 
boolean started-false; 

Thread runner; 
LinkStateAdvertisement LSA - null; 
Vector interfaces; 
LinkStateMonitor monitor; 


boolean idChange-false; 


f| Coe АКО he e ke ehe he he ВЕЗА АЈА ko ko ck ko 


ЖЖЖЖ 


this thread will check the status of the Interfaces and generate an 


extra 


LSA if the status of the Interface is down or 


ХХХ ХХХХХХЖХХХХХХХХХХХХЖХХХХХХХХХХХХХХХХХЕХХХЖХХЖХХХХХХЖХХХХХХХХЖХЕЕХАжАХЖХЭЖ 


ххжж/ 


private Thread intChecker; 


private 


Timer checkTimer; 


private boolean go-false; 


private Object checkLock-new Object(); 


public LsaGenerator(ControlExecutive control) { 


gui = 


new SAAMRouterGui("LsaGenerator"); 


this concerolExee - ЕСПЕСОВ; 
controlExec.registerMessageProcessor (this); 
sourcePort = (short)controlExec.listenToRandomPort (this); 
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destPort = (short)controlExec.SAAM_CONTROL_PORT; 
numberOflInterfaces = controlExec.getNumberOfInterfaces(); 
timeBetweenLSAGenerations = LSA_PERIOD; 

interfaces = controlExec.getInterfaces(); 


//add yourself as talker to ACE 
int channel-ProtocolStackEvent.FROM LSAGENERATOR TO ACE; 
tryí 

controlExec.addTalkerToChannel(this,channel); 
}catch(ChannelException ce) { 

gui.sendText ("Could not register as talker to ACE"); 
} 
channel=ProtocolStackEvent . PACKETFACTORY_CHANNEL; 
try{ 

controlExec.addTalkerToChannel (this,channel); 
}catch (ChannelException ce2) { 

gui.sendText ("Could not register as talker to PACKETFAC"); 
} 


startInterfaceCheck(); 


)//end constructor 


public LsaGenerator(ControlExecutive control,int generationTime)( 
gui = new SAAMRouterGui ("LsaGenerator"); 
this.controlExec = control; 
controlExec.registerMessageProcessor (this); 
sourcePort = (short)controlExec.SAAM_CONTROL_PORT'; 
destPort = (short)controlExec.SAAM_CONTROL_PORT; 
timeBetweenLSAGenerations = generationTime; 
interfaces = controlExec.getInterfaces(); 
startiInterfaceCheck(); 

}//end constructor 


private void startInterfaceCheck () { 
Runnable check = new Runnable() { 
public void run(){ 
while(true)( 
try 
synchronized (checkLock) { 
while(!go) { 
checkLock.wait(); 
} 
} 
checkInterface(); 
}catch (InterruptedException e){ 
System.out.printin(e); 
System.exit(1); 


) 
)//while 
) 
Tu 
intChecker - new Thread(check,"InterfaceChecker"); 
intChecker.start(); 


checkTimer = new Timer(2000,new ActionListener(){ 


FT 


public void actionPerformed(ActionEvent event) { 
gui.sendText ("Timer expired. Interface check ..."); 
synchronized (checkLock) { 
go = true; 
checkLock.notify(); 
) 
} 
79? 
checkTimer.start (); 


} 


private void checkInterface() { 
synchronized(interfaces) { 

gui.sendText ("Checking interfaces."); 

Enumeration enum=interfaces.elements(); 

while (enum.hasMoreElements() ) { 
Interface temp=(Interface) enum.nextElement () ; 
//check the status of the interface 
if(!temp.getState()) { 

//check if the interface lsa has been sent before if so dont 


bother to 
//send it a second time 
if(!temp.isLSASent () ) { 
generateExtraLSA (temp) ; 
performLSACycle(); 
} 
}//end if 
}//end while 
go=false; 


}//end synchronized block 
)//checkInterface 


public void setGenerationTime(int newTime) { 
if(newTime < this.LSA_PERIOD) { 


gui.sendText("Can not set generation time to a value smaller than 
default"); 


return; 
} 
timeBetweenLSAGenerations = newTime; 
timer.setDelay (timeBetweenLSAGenerations) ; 


} 


public int getGenerationTime()( 
return timeBetweenLSAGenerations; 


} 


public void startAction(){ 
gui.sendText ("Generating LSAs "); 
decideRouterID(); 
timer = new Timer (timeBetweenLSAGenerations,this); 
timer.setInitialDelay (25000); 
timer.start(); 
runner = new Thread(this, "Runner") ; 
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runner.start(); 
} 


public void actionPerformed(ActionEvent event) { 
gui.sendText ("Timer event occured") ; 
synchronized (myLock) { 
started = true; 
myLock.notify(); 
} 
} 


public String[] getMessageTypes() { 
return messageTypes; 


} 


public IPv6Address getRouterID(){ 
return routerId; 


) 


public void ron) { 


while(true) { 
gui.sendText ("Taking InterfaceLSAs..."); 


performLSACycle(); 
gui.sendText("LSAs are sent, I'm going to sleep"); 
tryt 


synchronized (myLock)( 
gui.sendText("Waiting..."); 
while(!started) 
myLock.wait(); 


) 


Jcatch(InterruptedException іе) { 
gui.sendText (ie.toString()); 


} 
}//while (started) 


}//end method run() 


private synchronized void performLSACycle() { 
Vector iLsas=new Vector(); 
Enumeration enum = interfaces.elements(); 
while (enum. hasMoreElements () ) { 
Interface temp = (Interface)enum.nextElement () ; 
monitor = temp.getMonitor(); 


InterfaceLSA lsa = monitor.getLSA(); 


//if the status of the interface is down 
if (!temp.getState()) { 
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//check if the LSA is sent before 

if (!temp.isLSASent ()) { 
generateExtraLSA(temp) ; 
lsa.setLSAType (InterfaceLSA.REMOVE); 
checkIdChange(lsa.getIP()); 
temp.setLSASent(); 

) 

) 


iLsas.add(lsa); 
}//end while 
//construct the header of LinkStateAdvertisement for this router 
LSA = new LinkStateAdvertisement (routerId); 
LSA.insertInterfaceLSA(iLsas); 


if(idChange) { 
decideRouterID(); 
idChange = false; 
} 


//artik autocontrolexec e gonder 
//Now send the LSA via ControlExecutive 
//controlExec.sendLSA(LSA) ; 
int channel=ProtocolStackEvent .FROM_LSAGENERATOR_TO_ACE; 
MessageEvent me=new MessageEvent ( 

thıs-tostring(), 

this, 

channel, 

LSA); 
Сгу({ 

controlExec.talk(me); 

gui.sendText ("LSA gonderildi "+"at "+System.currentTimeMillis()); 
}catch(ChannelException che) { 

gui.sendText ("Could not send the LSA to ACE"); 
} 


// if the this is server LSA should also be sent to itself 
if (controlExec.getIsServer()) { 
long ts=System.currentTimeMillis(); 
byte[] data=me.getMessage().getBytes(); 
byte numbMes=1; 
data=Array.concat (numbMes, data) ; 
data=Array.concat (PrimitiveConversions.getBytes(ts) ‚data); 
int channelP-ProtocolStackEvent.PACKETFACTORY CHANNEL; 
ProtocolStackEvent pe=new ProtocolStackEvent ( 
this.tostring(), 
thas, 
channelP, 
data); 
try{ 
controlExec.talk (pe); 
}catch (ChannelException ce) { 
System.out.println(ce); 
) 
} 
started = false; 
)//end method performLSACycle() 
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to 


public Message query (Message message) { 


} 


return message; 


public void processMessage (Message message) { 


} 


gui.sendText ("Received Message: "+message.toString()); 
//here the server has requested that an LSA be sent. 
//Based on the parameters contained in the LsaRequest, 
//we would construct an LinkStateAdvertisement and 
//send it to the server 
//LinkStateAdvertisement lsa = 

//new LinkStateAdvertisement ( [parameters]); 
//sendLSA(lsa); 


public void receiveEvent (SaamEvent se) { 


ProtocolStackEvent event = (ProtocolStackEvent) se; 

int channel = event.getChannel_ID(); 

gui.sendText ("Received event from channel"+channel); 

//interfaceLSA came from the Interfacewe will add tje Interface LSA 


//LinkStateAdvertisement 


}//receiveEvent () 


private void decideRouterID() { 


//first, take the first Interface ip as the router id 
Enumeration enuml = interfaces.elements() ; 
Interface temp; 
while (enuml.hasMoreElements () ) { 
temp = (Interface) enuml.nextElement () ; 
if(temp.getState()){ | 
routerId = temp.getID() .getIPv6(); 
break; 


} 
)//first while 


//now check if there is another ip that is bigger than the first one 
Enumeration enum2=interfaces.elements(); 
while (enum2.hasMoreElements () ) { 
temp = (Interface) enum2.nextElement(); 
if (temp.getState() & !routerId.equals(temp.getID().getIPv6()))f{ 
byte[] tempBytes = temp.getID().getIPv6().getAddress(); 
byte[] idBytes- routerId.getAddress(); 


for (int ix=0;ix<IPv6Address.length;ix++)( 
if(idBytes[ix]»tempBytes[ix])( 
break; 
) 
if(idBytes[ix]«tempBytes[ix])( 
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routerId = temp.getID().getIPv6(); 
break; 
} 
ЈУ БОР 
DAZ PE 
)//end 2nd while 
)//end method decideRouterID() 


/** 
* 
* 
*/ 
public void generateExtraLSA(Interface parent) { 


LinkStateMonitor tempMonitor=parent.getMonitor(); 

InterfaceLSA tempLSA-tempMonitor.getLSA(); 
tempLSA.setLSAType(InterfaceLSA.REMOVE); 

LinkStateAdvertisement LSA=new LinkStateAdvertisement (routerld) ; 
LSA.insertInterfaceLSA(tempLSA); 


//I need to send other Interface LSAs since Server will look for 
router id 
//change when it receives the LSA 
Enumeration enum-interfaces.elements(); 
while(enum.hasMoreElements())( 
Interface iFace=(Interface) enum.nextElement (); 
if (iFace.equals(parent) ) { 
continue; 
} 
LinkStateMonitor iMonitor=iFace.getMonitor(); 
InterfaceLSA 1LSA=iMonitor.getLSA(); 
LSA. insertInterfaceLSA(iLSA) ; 
}//end while 


controlExec.sendLSA(LSA) ; 


)//end generateExtraLSA() 


private void checkIdChange(IPv6Address ip)( 
if(routerlId.equals(ip))( 
idChange=true; 
//decideRouterID(); 
} 
} 


public String toString()({ 


return ("LsaGenerator"); 


} 


}//end class LsaGenerator 
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APPENDIX D. LINKSTATEADVERTISEMENT CLASS SOURCE CODE 


package saam.message; 


import java.net.UnknownHostException; 
import java.util.Vector; 


import saam.net.*; 
import saam.util.*; 


/** 
* LinkStateAdvertisement are sent by the routers in a SAAM network to 
* keep the server abreast of their state. The server makes routing 
decisions 
* and adjustments to the network based on the LinkStateAdvertisements 
ШЕ : 
* receives. 
*/ 
public class LinkStateAdvertisement extends Message { 


public static final int indexOfNumberOfInterfaces =17; 
private IPv6Address myIPv6 - new IPv6Address(); 
private byte [] payload; 

Vector interfaceLSAs; 


byte[] data; 
byte numOfInterfaces =0; 


/** 
* Used by the Server. 
Ey 

public LinkStateAdvertisement (IPv6Address ip) { 
super (Message.LSA) ; 


myIPv6-ip; 

payload = Array.concat (Message.LSA, payload) ; 

payload - Array.concat(payload,myIPv6.getAddress()); 
payload - Array.concat(payload,numOfInterfaces); 


interfaceLSAs - new Vector(); 


public LinkStateAdvertisement(byte[] lsaByte)( 
interfaceLSAs - new Vector(); 


payload = lsaByte; 

int index = 0; 

//£irst byte is message type 

byte mType=payload[index++]; 
//second item is ip address 16 bytes 
try{ 


p 


myIPv6 = new 
IPv6Address (Array.getSubArray (payload, index, index+IPv6Address.length)); 
}catch (UnknownHostException e){ 
System.out.println(e); 
) 
index+=IPv6Address.length; 
//third item is Number of interfaces 1 byte 
numOfInterfaces = payload[index++] ; 


//now we will create "numOfInterfaces" InterfaceLSAs 
byte slpNum=0; 
int lengthOfLSA=0; 


for(int i=0;i<numOfInterfaces;i++) { 
slpNum = payloadlindex+InterfaceLSA.SLPNumIndexOffset]; 
lengthOfLSA - InterfaceLSA.headerLength + (slpNum*SLPLSA.length) ; 
InterfaceLSA lsa - new InterfaceLSA( 
Array.getSubArray (payload,index,index«lengthOfLSA)); 
index+=lengthOfLSA; 
interfaceLSAs.add(lsa) ; 


public byte[] getBytes() { 
return payload; 
} 


/** 
* Returns the IPv6Address of the sender. 
* (return The IPv6Address of the sender. 
2 

public IPv6Address getMyIPv6 () { 
return myIPv6; 

} 


/** 
* Returns the length of this Message. 
зкеспіп Ihe length of this Message. 
27 

public short length(){ 
return (short)payload.length; 

1 


/** 
* Returns a «code»String«/code» representation of this Message. 
* @return The <code>String</code> representation of this Message 
Ху 

públic String сабе та) 
return "Link State Advertisement"; 


} 


public void insertInterfaceLSA(InterfaceLSA lsa) { 
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//increment the number of interface lsas 
num0fInterfaces++; 


//update the byte[] at number of interfaces 
payload{indexOfNumberOfInterfaces] = numOfInterfaces; 


payload = Array.concat (payload, lsa.getBytes()); 
interfaceLSAs.add(lsa); 
) 


public void insertInterfaceLSA(Vector V) { 
numOfInterfaces += V.size(); 


payload[indexOfNumberOfInterfaces] = numOfInterfaces; 


for(int i=0;i<V.size() ;i++) { 
InterfaceLSA temp = (InterfaceLSA)V.elementAt (i); 
payload = Array.concat (payload, temp.getBytes()); 
interfaceLSAs.add(temp) ; 
} 
} 


public Vector getLSAs()( 
return interfaceLSAs; 


) 


public byte getNumberOfInterfaces() { 
return numOfInterfaces; 


} 


}//end link state Advertisement 
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APPENDIX E. INTERFACELSA CLASS SOURCE CODE 


package saam.message; 


import java.util.Vector; 

import java.util.Enumeration; 

import java.net.UnknownHostException; 
import java.lang.IndexOutOfBoundsException; 


import saam.net.IPv6Address; 

import saam.util.*; 

public class InterfaceLSA { 
public static final byte UPDATE 


public static final byte ADD 
public static final byte REMOVE 


"uu 
to p o 


public static final int SLPNumIndexOffset = 21; 


/** 
* 0 update this interface 
* 1 add this interface 
* 2 remove this interface 
ur 


byte LSAtype; 
IPv6Address interfaceIP; 


//Kbps - 10000 is 10 MBps 
int bandwith; 
byte numOfSLPs -0; //default none 


Vector SLPs - new Vector(); 


/** 
* IP length + bandwithlength(4) + lsatype (1) + numof SLPLSA (1) 
Зу 
public static final int headerLength = IPv6éAddress.length+ 4 + 1 + 1; 


byte [] bytes; 


/** 
* constructor of the class 
* if no type is specified this means it is an update as default 
*/ 
public InterfaceLSA(IPv6Address ipNum,int bandwith) { 
interfaceIP = ipNum; 
this.bandwith = bandwith; 
LSAtype = UPDATE; //this is default 


bytes = Array.concat (LSAtype, bytes) ; 
bytes = Array.concat (bytes, ipNum.getAdäress()); 
bytes = Array.concat (bytes, PrimitiveConversions.getBytes (bandwith)); 
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} 


/** 
* constructs an InterfaceLSA with the specified InterfaceLSA type 
* Qparam ipNum IPv6Address of the interface 
* Qparam bandwith int bandwith of the Interface 
* @param type byte LSAtype 
zy. 
public InterfaceLSA(IPv6éAddress ipNum,int bandwith,byte type) { 
interfaceIP = ipNum; 
this.bandwith = bandwith; 
LSAtype = type; 


bytes = Array.concat (LSAtype, bytes) ; 
bytes = Array.concat (bytes, interfaceIP.getAddress()); 
bytes = Array.concat (bytes, PrimitiveConversions.getBytes (bandwith) ); 


)//end constructor 


public InterfaceLSA(byte[] data) throws IndexOutOfBoundsException( 
bytes - data; 
int index=0; 
LSAtype = bytes[index++]; 


try t 
interfaceIP = new IPv6Address(Array. 


getSubArray (bytes, index, index+IPv6éAddress.length) ); 
}catch (UnknownHostException uhe) { 
System.err.println("Error in creating the IPv6Address for 
InterfaceLSA"); 


} 
index+=IPv6Address.length; 


bandwith = 

PrimitiveConversions.getlInt (Array.getSubArray (bytes, index, index+4)); 
index+=4; 
numOfSLPs = bytes[index++]; 


for (int i=0;i<num0fSLPs;i++)( 


SLPLSA lsa - new 
SLPLSA(Array.getSubArray (bytes,index,index-SLPLSA.length)); 
index+=SLPLSA. length; 
SLPs.add(1sa): 
} 


public void insertSLP(Vector slpVector) { 
SLPs = slpVector; 
numOfSLPs += (byte)SLPs.size(); 
byte[] slpByte=null; 


Enumeration enum = SLPs.elements(); 

while (enum.hasMoreElements() ) | 
SLPLSA lsa = (SLPLSA)enum.nextElement () ; 
slpByte = Array.concat (slpByte,1lsa.getBytes()); 
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Array.concat (bytes, numOfSLPs); 
Array.concat (bytes, slpByte); 


bytes 
bytes 


public void insertSLP(SLPLSA 15а)( 
//increase the number of SLPs by 1 
numOfSLPs++; 


//update the number of SLPs 
bytes [SLPNumIndexOffset] =numOfSLPs; 


bytes=Array.concat (bytes, 1sa.getBytes ()); 


} 


public Vector getSLPs() { 
return SLPs; 


} 


public byte[] getBytes() { 
return bytes; 


} 


public byte getNumOfSLPs()( 
return numOfSLPs; 
} 


public IPv6Address getIP(){ 
return interfacelP; 
} 


public void setLSAType (byte буре) { 
LSAtype = type; 
руге5 [0] =<уре; 

) 


public byte getLSAType()( 
return LSAtype; 
} 


public int getBandwith() { 
return bandwith; 


) 


Bublıe Sering tostring()t 
return "InterfaceLSA"; 
} 
)//end class InterfaceLSA 


//end file InterfaceLSA.java 


83 





APPENDIX F. SLPLSA CLASS SOURCE CODE 


package saam.message; 


import saam.util.Array; 
import saam.util.PrimitiveConversions; 


public class SLPLSA { 


private byte SLPNum; 
private byte utilization; 
private short delay; 
private short lossRate; 


public static final double UTIL_UNIT = 0.58; 
public static final double LOOSRATE_UNIT = 0.01d; 


//length of the SLPLSA 
public static final int length = 6; 


byte [] bytes; 


Max 
* constructor of the SLPLSA 
* Qparam number byte number of this SLP 
* Qparam util byte utilization of the SLP - between 0 and 200 
= 200 means 100 percent utilization - unit 
increment is 0.5 
* @param delay short delay in this SLP in ms 
* @param loss short loss rate of this SLP - between 0 and 10000 
= 10000 means 100 percent utilization - unit 
increment is 0.01 
E 
public SLPLSA(byte number,byte util, short delay,short loss) ( 


SLPNum = number; 
ШЕЛЕК а Өл о 2 util 
this.delay = delay; 
lossRate = loss; 


bytes = Array.concat (SLPNum, bytes); 
bytes = Array.concat (bytes, utilization); 
bytes = Array.concat (bytes, PrimitiveConversions.getBytes (delay) ); 


bytes = Array.concat (bytes, PrimitiveConversions.getBytes(loss)); 
}//end constructor 


/** 
* constructs a service level pipe link state advertisement 
* Qparam data byte[] that will be used to form a SLPLSA 
m 
public SLPLSA(byte[] data) { 
if(this.length!=data.length) { 
System.out.println("Error : wrong number of bytes"); 
) 
bytes = data; int index=0; 
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SLPNum = bytes[index++]; 

utilization = bytes[index++]; 

delay = PrimitiveConversions.getShort (Array. 
getSubArray (bytes, index, index+2) ) ; 

index += 2; 

lossRate = PrimitiveConversions.getShort (Array. 
getSubArray (bytes, index, index+2)); 

17 /епа constructor 


/** 
* returns the utilization of the slp 
* @return byte 
x} 
public byte getUtilization() { 
return utilization; 
}//end method getUtilization() 


/** 
* returns the delay of the slp 
* Qreturn short 
*/ 
public short getDelay() { 
return delay; 
)//end method getDelay() 


/** 
* returns the loos rate of the slp link state advertisement 
* Qreturn short 
xy 
public short getLossRate() { 
return lossRate; 
)//end method getLossRate() 


/** 
* returns the service level pipe number 
* @retun byte 
*/ 
public byte getSLPNum() { 
return SLPNum; 
}//end method getSLPNum() 


/** 
* returns the byte array representation of the data members 
* Qreturn byte[] 
"y 
public byte[] getBytes()( 
return bytes; 
}//end method getBytes() 


/** 

* return a string representing the class 

* Greturn String 

Bof 
public String toString (){ 

return "MAnService Level Pipe Link State Advertisement n"; 
}//end method toString() 
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APPENDIX G. INTERFACEFAILURE CLASS SOURCE CODE 


package saam.message; 


import java.net.UnknownHostException; 


import saam.net.*; 
import saam.util.*; 


public class InterfaceFailure extends Message { 


public static final int length = IPv6Address.length+l; 
private IPv6Address interfaceIP; 
private byte[] bytes; 


public InterfaceFailure(IPv6Address ip) ( 

super (Message.FAILURE); 

interfaceIP - ip; 

bytes - Array.concat(Message.FAILURE,bytes); 

bytes - Array.concat(bytes,interfaceIP.getAddress()); 


} 


public InterfaceFailure(byte[] packet) { 
super (packet [0]); 
int index=1; 
try{ 
interfaceIP = new 


IPv6Address (Array .getSubArray (packet, index, index+IPv6Address.length) ) ; 


}catch (UnknownHostException ex){ 
System.out.println("Can not initialize IPv6address in 


InterfaceFailure"+ex) ; 


} 


} 
} 


public byte[] getBytes() { 
return bytes; 


} 


public short length()( 
return (short)bytes.length; 
} 


public IPv6Address getIP(){ 
return interfaceIP; 


) 
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APPENDIX H. SOURCE CODE OF LSA PROCESSING METHODS ADDED TO 
THE SERVER 


per 

* Receives link state advertisement messages from router and processes the 
* service level pipe status information that they contain. It begins by 

* checking to see if a router with the interface address described by this 

* LSA is known to the PIB. If such a router is known to exist, it then 

* checks to see if the service level pipe described by this LSA is known to 
* the PIB. If the service level pipe is known, then update its status. 

* Otherwise, add the SLP with the specified QoS characteristics. Finally, 
* update the effective QoS for the paths that pass over this service level 

* pipe by calling the determineEffectiveQoSForPaths(). 

* @param router A representation of a router as defined by an LSA. 

Er 
public void processLSA(LinkStateAdvertisement LSA) { 


System.out.println("Started ProcessLSA"); 

//who is the generating router 

IPv6Address routerld = LSA.getMyIPv6(); 

gut.sendText("An LSA arrived at "+System.currentTimeMillis()+" from "+routerId.toString()); 
long startTs,endTs; 


Vector IntLSAs = LSA.getLSAs(); 
System.out.println("took the vector of interface Isa."); 
Vector ips = new Vector(); 


boolean newRouter = false; 
int nodeld; 
String keyStr = routerld.toString(); 
boolean check=IPv6ToIntIdTable.containsKey(keyStr); 
if(check) { 
System.out.printIn("table contains the keystring"); 
} 
/Icheck if IPv6ToIntIdTable contains this router 
if('check) { 
System.out.println("This router is not in my table. \nTaking InterfaceLS As from LSA message."); 
Enumeration enum = IntLSAs.elements(); 
while(enum.hasMoreElements()) { 
System.out.println("inside while."); 
InterfaceLSA tempLsa-(InterfaceLS A)enum.nextElement(); 
IPv6Address tempIp=tempLsa.getIP(); 
ips.add(tempIp); 
} 
/Icheck if there is a router with these interafces 
//this means we removed an interface which was a router id earlier and 
//routerid has changed in the table 
nodeld=PIB.doesRouterExist(ips); 
/hf the router is not in the pib it is a new one 


9] 


if(nodeld==this. ROUTERNOTINPIB){ 
System.out.printIn("Router is a new router."); 
newRouter - true; 
nodeld=PIB.getNewNodeld(); 
this.IPv6ToIntIdTable.put(keyStr,new Integer(nodeld)); 


else{ //it is not a new one this Isa is a second copy of the removal LSA 
System.out.printin("LSA exit earlier"); 
return; 
} 
} 


System.out.printIn("in ProcessLSA 1"); 


if(mewRouter) { 

//addd all interfaces to the PIB anc compute the Paths 

int IdInt = ((Integer)IPv6TolntldTable.get(keyStr)).intValue(); 

InterfaceLSA newlInterface-null; 

Enumeration enum=IntLSAs.elements(); 

while(enum.hasMoreElements())( 
newInterface=(InterfaceLSA)enum.nextElement(); 
this.checkAndAdd(IdInt,newInterface); 

) 

findAllPossiblePaths(); 

determineEffectiveQoSForPaths(); 

return; 


} 
System.out.println("in ProcessLSA 2"); 


//it may be a new or an old router take the int id of the router 
nodeld z ((Integer)IPv6ToIntIdTable.get(keyStr)).intV alue(); 


Enumeration IsaInterfaceEnum = IntLSAs.elements(); 
while(IsaInterfaceEnum.hasMoreElements()) ( 
InterfaceLSA curInterface-(InterfaceLS A)lsaInterfaceEnum.nextElement(); 
byte type = curInterface.getLSAT ype(); 
gui.sendText("Type of the InterfaceLSA is "+(int)type); 
switch(type){ 
case InterfaceLSA.ADD: 
checkRouterld(routerld,IntLSAs); 
checkAndAdd(nodeld,curInterface); 
if(!newRouter){ //another interface is added to the router 
//PIB will be updated 
findAllPossiblePaths(); 
determineEffectiveQoSForPaths(); 


} 
break; 


case InterfaceLSA.UPDATE: 


updatePIB(nodeld,curInterface); 
break, 
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case InterfaceLSA.REMOVE: 
checkRouterld(routerld,IntLSAs); 
removelnterfaceFromPIB (nodeld,curInterface); 
break; 


default: 
gui.sendText("Interface LSA type is not a recognized type."); 
}//end switch 
}//end while 


System.out.printin("end of ProcessLSA"); 
} //end processLSA 


private void checkRouterld(IPv6Address routerld, Vector iLsaVector)( 
IPv6Address tempIP; 
IPv6Address templd=new IPv6Address(); 
InterfaceLSA tempIntLsa; 
byte[] idBytes; 
byte[] tempBytes; 
Enumeration enum=iLsaVector.elements(); 
while(enum.hasMoreElements()) ( 
tempIntLsa = (InterfaceLSA)enum.nextElement(); 
if(tempIntLsa.getLS AT ype()==InterfaceLSA-REMOVE){ 
continue; 
} 
tempIP=tempIntLsa. getIP(); 
idBytes-templd.getAddress(); 
tempB ytes- tempIP.getAddress(); 
for(int i=0;i<IPv6Address.length;i++){ 
if(idB ytes[i]>tempB ytes[i]) { 
break; 


} 
if(idB ytes[i]<tempB ytes[i]) { 
templd=tempIP; 
break; 
} 
} 
} 


if(tempId.equals(routerId)) (//there is no change in id 
return; 
} 
//there is change in the router id 
//old router id has to be changed from the table 
int knownId-((Integer)IPv6ToIntIdTable.get(routerId.toString())).intValue(); 
IPv6ToIntIdTable.remove(routerld.toString()); 
routerId-templd; 
IPv6ToIntIdTable.put(tempId.toString(),new Integer(knownId)); 
}//end checkRouterld() 
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private void checkAndAdd(int nodeld,InterfaceL SA curInterface)( 


IPv6Address ip=curInterface.getIP(); 
int bandwidth=0; 
ІЛ this interface in my Path Information Base 
if( IPIB.doesInterfaceExist(ip))( 
bandwidth = curInterface.getBandwith(); 


if(!PIB .doesLinkExist(ip)) { 
PIB.addLink(ip,band width); 
}//end inner if 


//now add interface 
PIB.addInterface(nodeld,ip); 


/ladd service level pipes 
byte slps=curInterface.getNumOfSLPs(); 
Vector slpVector-curInterface.getSLPs(); 
for(int i=0;i<slps;i++){ 
gui.sendText(" Adding SLP"); 
SLPLSA slpLsa = (SLPLSA)slpVector.elementAt(i); 
byte slpNumber = slpLsa.getSLPNum(); 
byte utilization = slpLsa.getUtilization(); 
short delay = slpLsa.getDelay(); 
short lossRate = slpLsa.getLossRate(); 
PIB.addSLP(ip,sipNumber,INITIALDELAY ‚INITIALLOSSRATE,INITIALTHROUGHPUT); 
PIB.updateSLP(ip,slpNumber,delay,(int)(lossRate/100),(utilization/2)); 
} 
V//end if 


j 


private void updatePIB (int nodeld,InterfaceLSA iLsa)( 

byte slps=iLsa.getNumOfSLPs(); 

Vector slpVector-iLsa.getSLPs(); 

IPv6Address ip-iLsa.getIP(); 

for(int i=0;i<slps;i++) { 
SLPLSA slpLsa=(SLPLSA)slpVector.elementAt(i); 
byte sIpNumber=slpLsa.getSLPNum(); 
byte utilization-slpLsa.getUtilization(); 
short delay = slpLsa.getDelay(); 
short lossRate = slpLsa.getLossRate(); 
PIB.updateSLP(ip,slpNumber,delay,(int)(lossRate/100),(utilization/2)); 


private void removelnterfaceFromPIB(int nodeld,InterfaceLSA curInterface) { 
gui.sendText("Removing interface from PIB."); 
removePathsTraversingInterface(curInterface); 


94 


removeLinkFromPIB (curInterface. getIP()); 
removelnterfaceFromNode(curlInterface.getIP()); 


} 


private void removePathsTraversingInterface(InterfaceL S A iLsa)( 
gui.sendText("Removing Paths using the interface from PIB."); 
for(int i=0;i<iLsa.getNumOfSLPs();i++){ 
Vector pathIds=PIB.getAllPathIdsThatTraverseSLP(iLsa.getIP(),i); 


ClassObjectStructure cos=(ClassObjectStructure)PIB; 
cos.deletePathsTraversingInterface(pathIds); 


} 
} 


private void removeLinkFromPIB(IPv6Address ip) { 
gui.sendText(" Removing linkof the interface from PIB."); 
IPv6Address netIP=ip.getNetworkAddress(); 
ClassObjectStructure cos=(ClassObjectStructure)PIB; 
cos.links.remove(netIP.toString()); 


) 


private void removelInterfaceFromNode(IPv6Address ip)( 
gui.sendText(" Removing Interface from nodes."); 
ClassObjectStructure cos=(ClassObjectStructure)PIB; 
cos.nodes.remove(ip.toString()); 


} 
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